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Abstract 

This paper describes an update of the Space 
Telecommunications Radio System (STRS) open architecture 
for NASA space based radios. The STRS architecture has 
been defined as a framework for the design, development, 
operation and upgrade of space based software defined radios, 
where processing resources are constrained. The architecture 
has been updated based upon reviews by NASA missions, 
radio providers, and component vendors. The STRS Standard 
prescribes the architectural relationship between the software 
elements used in software execution and defines the 
Application Programmer Interface (API) between the 
operating environment and the waveform application. 
Modeling tools have been adopted to present the architecture. 
The paper will present a description of the updated API, 
configuration files, and constraints. Minimum compliance is 
discussed for early implementations. The paper then closes 
with a summary of the changes made and discussion of the 
relevant alignment with the Object Management Group 
(OMG) SWRadio specification, and enhancements to the 
specialized signal processing abstraction. 

Introduction 

Since the original release of the STRS architecture (refs. 1 
and 2), NASA has received comments. A consistent theme has 
been to increase the detail of the architecture. NASA has 
recently released STRS Architecture Standard Version 1.01 
(ref. 3), which is an update and has improved the details of the 
software architecture. A key focus of the updates has been 
refining the STRS infrastructure and the specific STRS API. 


The STRS infrastructure is part of the General Purpose 
Processor (GPP) Operating Environment (OE) and provides 
the functionality for the interfaces defined by the STRS API 
specification. Once the waveform is deployed, the 
infrastructure supports the waveform operations through the 
STRS API and its internal subsystems. The infrastructure is 
composed of multiple subsystems that interoperate to provide 
the functionality to operate the radio. The components shown 
in figure 1 represent the high level subsystems and services 
needed to control waveforms and applications within the radio 
platform. These services are provided by the platform 
infrastructure and support applications as they execute within 
the radio platform. 

The infrastructure implements the STRS API. The STRS 
API is the well-defined set of interfaces used by the waveform 
applications to access specific radio functions or used by the 
infrastructure to control the waveform applications. The STRS 
API provides the interfaces that allow applications to be 
instantiated and use platform services. This API also enables 
communication between waveform and application 
components. The STRS API includes support of external 
interface commands for normal radio operations. It hides the 
routine names actually used by the STRS infrastructure from 
the waveforms to facilitate portability. Although the STRS 
infrastructure may use any combination of Portable Operating 
System Interface (POSIX), real time operating system 
(RTOS), board support package (BSP) functions, or other 
infrastructure methods to support radio functions, which may 
vary on different platforms, the STRS API will be identical to 
allow portability. 
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Figure 1. — STRS infrastructure. 

STRS API 

The STRS API provides an open software specification for 
the application engineer to develop STRS waveform 
application programs. The goal is to have a standard API 
available to cover all application program requirements so that 
the waveform programs can be reused on other hardware 
systems with minimal porting effort and cost of the waveform 
software (and firmware) development. Two trade-offs in the 
development of the API specification are a) the larger the API 
specification then the greater the software overhead, which 
affects size, weight, and power (SWaP) and b) standardization 
of the API which limits the ability to use custom routines for 
optimization. The STRS API definition minimizes 
dependencies on specific capabilities of the GPPs. 

The API layer specification decouples the intellectual 
property rights of platform, waveform, and module 
developers. The API layer allows development and 
interoperability of different radio aspects while protecting the 
investment of the developers. 

STRS Application Control API 

A key aspect of a software architecture is the definition of 
the API that is used to facilitate software configuration and 
control of the target platform. The philosophy, on which the 
STRS architecture is based, avoids the conflict between open 
architecture and proprietary implementations by specifying a 
minimum API used to execute waveform applications and 
deliver data and control messages to installed hardware 
components. 
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Figure 2. — STRS waveform/device structure. 

Figure 2 is a class diagram in Unified Modeling Language 
(UML) that illustrates the inheritance between the classes and 
the corresponding implementation objects in C++. In a C or 
C++ implementation, it depicts the hierarchy of include files. 
The figure also shows a grouping of API. A waveform or 
service is a STRS Application implementation object that 
must implement the STRS Application Control API. The 
STRS Application Control API is comprised of the STRS 
Componentldentifier, STRS ControllableComponent, STRS 
LifeCycle, STRS Property Set, and STRS TestableObject API 
groups. 

STRS requires the methods shown in table 1 to be 
implemented by each waveform or service. The STRS 
Application Control API exhibits similar functionality to a 
Resource Interface in the OMG SWRADIO or SCA 
specifications except that the notion of ports has been replaced 
with the optional source or sink. The API may be implemented 
using the same OMG SWRadio Platform-Independent Model 
(PIM). 
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TABLE 1.— STRS APPLICATION CONTROL API 


WFConfigure 

Set values for one or more properties in 
the wavefonn. 

WFGroundTest 

Perform unit and system testing usually 
done on ground before deployment. The 
testing may include calibration. The 
method is similar to WF RunTest except 
that it contains more extensive testing that 
can be eliminated for actual flight. 

WF Initialize 

Initialize the waveform to a known initial 
state. Used to restart from the beginning 
rather than from where it left off. 

WFQuery 

Obtain values for one or more properties 
in the waveform. 

WF Read 

Method used to obtain data from the 
waveform. Optional. 

WF ReleaseObject 

Free any resources the waveform has 
acquired. An example would be to close 
open files or devices. 

WF RunTest 

Test the wavefonn. The tests provide aid 
in isolating faults within the wavefonn. 

WF Start 

Begin normal wavefonn processing. 

WF Stop 

End normal wavefonn processing. 

WFWrite 

Method used to send data to the 
wavefonn. Optional. 


STRS Infrastructure Application Control API 

The Infrastructure Application Control methods shown in 
table 2 correspond to the STRS Application Control API exactly 
and are used to access those methods. These methods are 
implemented by the STRS infrastructure but may be used by any 
STRS Application or any part of the infrastructure that is desired 
to be implemented in a portable way. A handle ID is an identifier 
that is used to control access to applications and resources such as 
another waveform, device, file, or message queue. 

TABLE 2.— STRS INFRASTRUCTURE APPLICATION 


CONTROL API 


STRSC onfigure 

Set values for one or more properties 
in the waveform (or device). 

STRSJjroundTest 

Perfonn unit and system testing, 
including calibration, usually done on 
ground pre-deployment. 

STRS Initialize 

Initialize the wavefonn. Used to restart 
from the beginning rather than from 
where it left off. 

STRSQuery 

Obtain values for one or more 
properties in the wavefonn (or device). 

STRSJlead 

Method used to obtain data from a 
source or supplier. 

STRS ReleaseObject 

Free any resources the wavefonn has 
acquired. An example would be to 
close open files or devices. 

STRSRunTest 

Perfonn built in test. 

STRS_Start 

Begin nonnal waveform processing. 

STRSStop 

End nonnal wavefonn processing. 

STRSJWrite 

Method used to send data to a sink. 


STRS Infrastructure Application Setup API 

The Infrastructure Application Control Setup methods 
shown in table 3 are used in general or to control one 
waveform from another. A handle ID is an identifier that is 
used to control access to applications and resources such as 
another waveform, device, file, or message queue. 


TABLE 3.— STRS INFRASTRUCTURE APPLICATION 
CONTROL SETUP API 


STRSAbortApp 

Abort a wavefonn or service 

STRSGetErrorQueue 

Transform an error code into an 
error queue. 

STRS GetSizeOfProperties 

Compute number of bytes in a 
STRS Properties struct 
containing a given maximum 
number of STRS Property 
name/value structs. The number 
returned is used to allocate space 
for the STRS Properties struct. 

STRSHandlcRcquest 

The table of object names is 
searched for the given name and 
the handle ID is returned that is 
used to control access to another 
wavefonn, device, file, or 
message queue. 

STRS InitComplete 

Return initialization completion 
status when the task is initiated 
independent of the completion. 

STRS InstantiateApp 

Instantiate a waveform or service 
(or device). 

STRS IsOK 

Return tme, if return value of 
previous call is not an error code. 

STRSLog 

Send log message for distribution 
as appropriate. Time stamp is 
added automatically. 

STRSRemoveApp 

Remove specified waveform or 
service from persistent storage. 

STRSUploadC omplete 

Return upload completion status. 

STRSUp lo adReques t 

Begin or continue upload. 


STRS Infrastructure Device Control API 

STRS Devices are controlled using the STRS Infrastructure 
Device Control API shown in table 4. A STRS Device is a 
proxy for the data and/or control path to the actual hardware. 
A STRS Device may use any available platform-specific 
Hardware Abstraction Layer (HAL) to communicate with and 
control the specialized hardware. A STRS Device may also be 
used to hide the details of networking from the waveform. The 
purpose of abstracting the hardware interfaces in a standard 
manner is to make the waveforms more portable. A STRS 
Device is a STRS application that responds to the STRS 
Infrastructure Application Control API calls as well as to the 
following additional calls. 
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TABLE 4.— STRS INFRASTRUCTURE DEVICE 
CONTROL API 


STRSDeviceClose 

Close the device. 

STRS De viceF lush 

Send any buffered data immediately 
to the underlying hardware and clear 
the buffers. 

STRS DeviceLoad 

Load a binary image to the device. 

STRS DeviceOpen 

Open the device. 

STRS DeviccRcset 

Reinitialize the device. Reset is 
normally used after the device has 
been started and stopped, before 
starting the device again. 

STRS DeviceStart 

Start the device. 

STRSDeviceStop 

Stop the device. 

STRS DeviceUnload 

Unload the device. 

STRS SetlSR 

Set the Interrupt Service Routine for 
the device. 


STRS Infrastructure Memory API 

These Infrastructure Memory methods shown in table 5 are 
used to isolate the memory manipulation on small and large 
platforms so that the memory is used in a portable way. On a 
small platform, the total available memory may be severely 
limited. On a large platform, the total available memory may 
be limited only by the size of a disk swap area. The same 
methods are used in both situations for portability. 


TABLE 5.— STRS INFRASTRUCTURE MEMORY API 


STRSClone 

Acquire a section of memory to use, copy 
data into it, and return the new memory 
location. 

STRS Release 

Release a section of memory previously 
acquired with STRS_Clone or 
STRSReserve. 

STRS Reserve 

Acquire a section of memory to use and 
return the new memory location. 


STRS Infrastructure Messaging API 

The messaging methods shown in table 6 allow STRS 
applications to use a single target handle ID to send messages 
between applications or to multiple parts of the radio. The 
ability for waveforms to communicate with other STRS 
applications is crucial for the operation of radio services as well 
as separating the receive and transmit functionality between two 
waveforms. The messaging API is implemented using a form of 
the Observer or Publish- Subscribe design pattern. 


TABLE 6.— STRS INFRASTRUCTURE MESSAGING API 


STRSQueueC reate 

Create a queue. 

STRS QueueDelete 

Delete a queue. 

STRSRegister 

Register an association between a 
publisher and subscriber. 

STRSUnRegister 

Remove an association between a 
publisher and subscriber. 


STRS Infrastructure Time Control API 

These Infrastructure Time Control methods shown in 
table 7 are used to access the hardware and software timers. 


TABLE 7.— STRS INFRASTRUCTURE TIME CONTROL API 


STRS GetNanoseconds 

Get the number of nanoseconds 
from the STRS TimeWarp object. 

STRSJIetSeconds 

Get the number of seconds from 
the STRS_TimeWarp object. 

STRSGetTime 

Get the current base time and the 
corresponding time of a specified 
type. 

STRSGetT imeW arp 

Get the STRS TimeWarp object 
containing the number of seconds 
and nanoseconds in the time 
interval. 

STRSSetTime 

Set the current time in the specified 
clock/timer by adjusting the time 
offset. 

STRS Synch 

Synchronize clocks. The action 
depends on whether the clocks to 
be synchronized are internal or 
external. 


Configuration Files 

STRS configuration files shall contain platform and 
waveform specific information for the installation and 
customization of waveforms. Platform configuration files 
provide the STRS infrastructure with information on what 
hardware devices and modules are installed in the system. The 
configuration files are used by the STRS Infrastructure to 
determine what files, devices, waveforms, and services are 
used by the STRS radio. The name of the starting 
configuration file is specified on the command line when 
initializing the STRS Infrastructure. If none is specified, a 
mission specific default would be employed. A waveform 
(STRS application) configuration file contains specific 
information that allows STRS to instantiate and configure the 
application. 

The format of the configuration files shall be defined in 
Extensible Markup Language (XML) using an XML Schema. 
The XML Schema Definition Language is an XML language 
for describing and constraining the content of XML 
documents. The XML can be preprocessed to optimize space 
on the STRS Radio memory while keeping the equivalent 
content. 

One approach to accomplish the preprocessing, used in the 
STRS Reference Implementation, is to use an XSL 
transformation. Here the XSLT language, which itself uses 
XPath, was used to specify how to transform the given XML 
input into the desired output. One suggestion for a more 
compact representation is S-Expressions, which could be used 
if a more compact representation is desired. 
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Platform Configuration Files 


The contents of a platform configuration file include a list 
of hardware modules having memory able to contain data and 
executable software. There is a unique module name for each 
hardware module accessible from the current GPP. The 
platform configuration file includes a list of memory areas of 
various types (e.g., ROM, RAM), sizes, units, and access. The 
platform configuration file includes a memory map list which 
provides the base name, base address, memory size, and 
memory read and write access. It also contains a module type 
which is the name of the hardware type. The module type may 
be the GPP, RF, FPGA, DSP, ASIC, etc. 

STRS Infrastructure Configuration Files 

The STRS Infrastructure configuration data is one example 
of the data that defines the infrastructure. The infrastructure 
configuration file includes a list of files to read, write, or 
append, from multiple locations using a handle ID. The file 
data includes a handle name, file name, file type and file 
access. The infrastructure configuration file includes a list of 
devices to read or write from multiple locations using a handle 
ID. The device data has a handle name, device name, device 
type, device access, and attribute list. The infrastructure 
configuration file includes a list of attributes that are tested 
against specific values to indicate the health of the system. 
The infrastructure configuration file includes a queue list 
containing the correspondences between publishers and 
subscribers. 

STRS Waveform Configuration Files 

A waveform (STRS application) configuration file contains 
specific information that 1) allows STRS to instantiate the 
application; 2) provides default configuration values; 3) 
provides connection references to devices, queues, and 
services needed by the application. 

An example of a waveform configuration file in XML is 
shown in figure 3. 

The contents of a STRS waveform configuration file 
include a handle name, that is a unique shortened form of the 
waveform name used in messages and a waveform name, 
(usually a shortened form of the waveform that will be the 
C++ class name). Access to the waveform may be specified as 
read, write, both, or none. Read indicates that the waveform 
implements WF_Read(). Write indicates that the waveform 
implements WF_Write(). The initial state is the state at which 
the waveform is left after processing the configuration file. 
The state may be instantiated or running. A file list contains a 
list of files to be loaded for execution and includes the file 
name and the target module name. An attribute list contains 
the list of properties having a name and value pair set as the 
default during initialization. 
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Figure 3. — Example STRS waveform configuration file in XML. 


STRS Minimum Compliance 

A minimum compliance has been defined for systems 
installed on constrained space platforms and that supports 
upwards compatibility on larger platforms. It is expected that 
this minimum compliance will be satisfactory on early STRS 
platforms, enabling the experience and lessons learned to 
feedback into further architecture definition. The minimum 
compliance builds upon the previously defined APIs and 
configuration files and adds the following additional elements 
discussed below. 

Minimum compliance requires publishing the Hardware 
Interface Definition (HID) and HAL, employing configuration 
files defined in XML (described by a XML schema), the use 
of selected POSIX subsets, and using the minimum list of the 
STRS API. The HID has been compared to an Interface 
Control Definition, with the requirement to publish interfaces 
and the operating requirements of the hardware system after 
delivery. The HAL in the GPP is software that configures, 
controls, and communicates with specialized hardware by 
abstracting the physical hardware interfaces. The HAL API 
shall be published so that specialized hardware made by one 
company may be integrated with the STRS Infrastructure 
made by a different company. Platform and waveform 
configuration files require the use of XML to describe the 
contents; however an approach for the expected 
transformation to a more compact form to meet space memory 
requirements is suggested but not mandated as part of the 
architecture. 


NASA/TM— 2008-215052 


5 


The STRS API is split into the STRS Application Control 
API and the STRS Infrastructure API. A waveform is a STRS 
Application and waveform developers must implement the 
STRS Application Control API listed above and defined in the 
STRS Architecture Standard. The STRS Infrastructure is part 
of the OE and provides the functionality for the interfaces 
defined by the STRS API specification. The STRS 
Infrastructure must implement the STRS API listed to support 
applications as they execute within the radio platform. 
Additional functionality must be implemented in the STRS 
infrastructure for radio robustness and mission dependent 
requirements. In addition, radio developers must provide the 
HID and HAL documentation. 

The STRS architecture requires that compliant radios must 
use a POSIX conformant RTOS, or provide a POSIX 
abstraction layer (minimum POSIX real time profile PSE51) 
to provide the POSIX API missing from RTOS. For 
constrained resource platforms, with limited software 
evolutionary capability, where the waveform signal processing 
is implemented in specialized hardware, the supplier may 
request permission from NASA to only implement a subset of 
POSIX PSE51 as required by the portion of the waveforms 
residing on the GPP. The waveforms created for this platform 
must be upward compatible to a larger platform containing 
POSIX PSE51. If none of the waveforms for a constrained 
resource platform use any of the interfaces in a unit of 
functionality, then the supplier may request permission from 
NASA to eliminate that entire unit of functionality. 

The difference between a POSIX conformant RTOS and a 
non-conformant RTOS is illustrated in figure 4. On the left 
side, the POSIX AEP is provided entirely by the RTOS. The 
POSIX API is included for the RTOS. On the right side, if the 
RTOS is not POSIX AEP conformant then a POSIX 
abstraction layer must be provided to implement the required 
missing functionality. 



Conclusion 

The STRS architecture has been updated, focusing on key 
elements of the software architecture. Reference 
implementations and early STRS compliant radios are being 
developed, and minimum compliance criteria are described. 
Future planned updates include adding more detail to 
specialized signal processing abstraction, the hardware 
architecture, and providing a waveform developer’s guide. 
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